Fields 不是資訊相關科班出身的，應用數學系畢業，雖然很喜歡數學，但是考慮謀生之道，自學了 C#，後來進入 T軟這家還算可以的公司，表現一直不上不下，這次自願到專案的原因在於他終於能發揮自己的數學底子。

在這個 Sprint Fields負責 『提昇專案成員AI 所需數學知識與對應Python程式』。但當他一開始嘗試以現在最火紅的 Tensorflow 作為他第一個機器學習的框架，他發現還蠻有挑戰的。他又嘗試諸如：PyTorch，MxNet，CNTK等等，最後他自己決定採用 Mxnet，因為它的整個結構讓 Fields 很容易按照自己數學邏輯來撰寫。但是這引起今日的Daily Scrum很大爭議。

Pete ：『決定採用哪個軟體框架，以前我們用 UP 因為專案本身就會有架構師這角色來定案，現在我們採Scrum，開發團隊不分角色，如果遇到意見分歧是否就變成投票表決？』

Molly 不急著回答，請幾位說明一下在 UP 對於架構設計這工作是如何運作。

對UP 前幾個Disciplines(Business Modeling, Requirement, Design) 的工作流程，這個佳麗可是高手，她之前是負責需求分析的，按照Waterfall 的作法，下一關就是就會有架構師做初步設計。但是UP為了保有彈性以應付後續需求演化或變更，這個初步設計一開始並不會花太多時間做太細緻的Software Architecture Document。但隨著需求演化成熟，例如到了Construction Phase 結束前，才逐步的被真正完整設計。

Molly 承接佳麗的說明，解釋道：”當然有按專業分工有他的好處，這邊我們先不討論。我們遇到的問題是我們還在 Inception Phase，甚至可以說是 Pre-Inception。整個專案的願景事實上還在摸索中，更不要談需求分析了，所以沒有需要做架構設計的工作，那就不會有人出來認領『架構設計的待辦事項』，如果這件事發生了，那個認領者無形中就會是架構師。但是大家知道的，我們不希望掛頭銜，以免發生劃分界線的困境。”

這個話題又衍生兩者優劣的討論，考慮 Daily Scrum的Time-Box快用光了。 Gavin與佳麗鼓舞大家另外再開一個臨時會。搞笑的是大家一起做一個挪移屁股的動作，還是留在原地。這是他們後來逐步形成的儀式，一個會議結束，如果緊接一個會議，與會者大致相同的話，要做出結束前會議的儀式來，他們要培養 Time-Box 是最高原則。

Gavin 針對這個臨時討論會議起個頭：”我們在本Sprint 有待辦事項，要熟悉 Scrum。目的要在未來可以幫忙改善現有 UP。。。。”

佳麗馬上頂上去：”喂！Gavin 你現在是 Product Owner 附身喔？講的太官腔啦！無非就是要討論 UP 有許多 Discplines，有角色分工。而 Scrum 是跨職能團隊合作完成待辦事項。我們要探討兩者優劣”。

Molly 馬上出面緩解這個『職場霸凌』：”Gavin上輩子一定有欠佳麗姐。我先談我已經遭遇過 Scrum 這樣的模式最大的缺點：專案進行後，如果真有需要補充成員，會是大問題，除了Scrum 對成員素質有很高的期望，更困難的是很難找到讓現有多數成員滿意的人。通常不是技術專業好不好的問題，而是總是有幾個人對 Candidate 有那種八字不合的莫名問題。”

Pete好一段時間在幫Gavin擴大部門，也想到問題：”我推估 Scrum 也比較難有一套方法或是機制來複製訓練人。我們採用 UP 在部門擴張時，每個專業角色，可以用師徒制，有經驗的帶剛畢業的慢慢成長，Cash 幾年前就是菜鳥被慢慢拉拔起來的。”

Cash苦笑：”我是因為站著所以中槍？”

Gavin補充：”因為 UP 各角色專業分工，我們找人就不那麼講究，例如：原需要的是Oracle資料庫設計師，來個較偏向SQL Server 的碼農，如果真缺，我們也敢用的。當然沒那麼優啦！而且我們也不會期望他能協助做分析，測試自動化的工作，不求是個全方位人才，這樣就好找人了。”

佳麗也加上她個人的經驗：”依角色分工其實也是讓每個新人沈澱自己的職業生涯是否要走這個專業，我剛進公司是你們說的碼農，可是我做的不開心。也謝謝 Gavin 跟我建議往開發測試自動化走。我開始接觸軟體測試，又慢慢熟悉Domain Knowledge的皮毛與術語，加上對客戶的溝通也可以，後來又遇到很好的師父帶，最後變成分析師。這個職涯規劃是按角色來看的，如果沒有特定角色扮演，很難系統化的談。”

這個課題大家有答案了。

備註：

專案的工作執行記錄在【深度學習所需入門知識--一位初學者的認知】